Multicasting of telecommunication services to access subscribers is a common modern solution for providing, to groups of the access subscribers, such broadcast services as TV services, video on demand and the like from a sender located beyond the access network.
In order to provide multicast services to a number of access subscribers, the required broadband service is sent as a single stream by a source/sender to an access node, and then the access node multicasts the received stream to the subscribers that ordered it.
Modern standard streaming protocols allow not only for streaming the required services, but also for evaluation of Quality of Experience (QOE), by collecting the QOE data from receivers of the services and by forwarding the collected QOE data to the source of the stream (at application layer).
However, in modern access networks, the above-mentioned method of QOE evaluation fails due to several reasons, and mainly due to the fact that the number of subscribers is very high so the sender of the multicast services cannot be aware of all the subscribers (receivers).
To be more specific, the presently known actual streaming applications utilize the following types of standard protocols:                Data forwarding protocols (e.g. RTP—Real time Transport Protocol) for the actual forwarding of the streamed data packets. The data forwarding protocols may include UDP (User Datagram Protocol) or TCP (Transport Control Protocol) for packet transport, and IP (Internet Protocol) for packet forwarding. The IP protocol allows both the unicast and the multicast forwarding of the frames.        Streaming control protocols (e.g. RTSP—Real Time Streaming Protocol) for controlling the streaming of the packets. The streaming control commands may include start, stop, fast forward rewind and other streaming commands.        
Streaming service control protocol (e.g. RTCP—RTP Control Protocol) for conveying control messages between the sender and the receiver(s). These messages allow the sender to indicate to the receiver how many packets were sent, and allow the receiver to respond how many packets were received, how many are missing, or are received with errors, etc. These protocols should allow the sender to modify the nature of streaming according to the reports received from the receivers.
For unicast conditions (one sender to one receiver), the above-described functions of the standard streaming protocols are performed properly. In cases where multicasting is required, the streaming protocol relies on the IP multicast data forwarding protocol to produce multiple streams to the users. However, the standard streaming control protocols cannot be used since, when one of the receivers commands to affect its specific stream, it affects all the remaining multicast streams and receivers. Such a situation is non-acceptable; as a result, the multicast streaming is not controlled today.
As to the streaming service control protocols, they theoretically can be used for multicast cases; however, the problem of numerous feedback responses sent by numerous receivers/subscribers to one and the same source makes these protocols problematic, at least due to the necessity to process all the responses.
IETF RFC 3550 [1], Tree Structure for Source-Specific Multicast with Feedback Aggregation [2] and US published application US2006/0069799 AA [3], describe several methods that allow multicast forwarding of control packets from sender to multiple receivers and further aggregation of receivers' feedback packets, sent from the receivers to the sender/source, at an intermediate node. These methods suppose that there is an ability of the streaming application in the sender to analyze and adapt the downstream service based on the aggregated feedback QOE control packets from the receivers.
However,                The sender's application is typically unaware of the specific receivers. This is a result of the multicast method in access nodes that multicast the streamed data based on previously learned data (usually via IGMP protocols).        Even if the sender application were aware of the receivers it could not do anything in response to the obtained streaming service control data (QOE), since for the sender application, any loss or error in a packet for a specific receiver must not degrade the user experience of the many other receivers that receive the same stream but, say, without errors.        Even if the burden on the sender applications is alleviated by aggregating the data on the path from the many receivers to the sender (as it was suggested in [1] and [2]), functionally there is nothing meaningful the sender application can do with the aggregated data for the same reasons: 1) the receivers are unknown and 2) that the streaming must continue to all receivers even in case when one of them has degraded.        
To the best of the Applicant's knowledge, none of the presently known streaming applications and none of the streaming service control protocols discuss how to handle QOE data collected from multiple receivers which are often unknown to the sender, none of them proposes an idea how to use this type of data, and none of them discusses or uses specific features of wire line access networks for handling that data.